What does this PR do?

This PR implements a booking audit log viewer as part of the Booking Audit Stack. It adds:

1. New tRPC endpoint (viewer.bookings.getAuditLogs) that fetches audit logs for a specific booking with permission checks
2. New page at /booking/logs/[bookinguid] to display the audit history
3. UI component with search, filtering by action type/actor, and expandable log details

Permission model: Only the booking owner, attendees, or team admins/owners can view audit logs for a booking.

Link to Devin run: https://app.devin.ai/sessions/1526633c2f714bcb88952e8cbcda9cfa
Requested by: hariom@cal.com (@hariombalhara)

Key Implementation Details

Backend (getAuditLogs.handler.ts)

• Fetches booking and verifies user has permission (owner, attendee, or team admin/owner)
• Retrieves all bookingAudit records for the booking UID
• Enriches actor information by looking up user details when userUuid is present
• Returns logs ordered by timestamp (descending)

Frontend (booking-logs-view.tsx)

• Displays audit logs with icons, timestamps, and actor information
• Supports filtering by action type and actor type
• Search functionality across action names and actor names
• Expandable details showing full log data as JSON
• Loading and error states

Human Review Checklist

⚠️ Critical areas to review:

1. Permission logic (getAuditLogs.handler.ts:44-81): Verify the permission checks cover all scenarios:

   • Is the booking owner check sufficient?
   • Should organization admins have access?
   • Are there any edge cases with team memberships?

2. Performance (getAuditLogs.handler.ts:108-142): The handler uses Promise.all to enrich actor data in a loop. For bookings with many audit logs, this could be slow:

   • Should we add pagination?
   • Can we optimize the actor enrichment with a single query?

3. Type safety: The enriched audit logs modify the structure from Prisma's return type. Verify TypeScript catches any type mismatches.

4. Internationalization: Some UI strings are hardcoded (e.g., "Booking History", action display names). Verify all user-facing text uses the translation system.

5. UI edge cases: The component hasn't been tested with:

   • Very large audit log datasets
   • Empty states (no logs)
   • Long JSON data in expandable sections
   • Mobile responsiveness

How should this be tested?

Prerequisites:

• Database with bookingAudit records populated
• Test users with different roles (booking owner, attendee, team admin, unrelated user)

Test scenarios:

1. Navigate to /booking/logs/{valid-booking-uid} as the booking owner → should see audit logs
2. Try accessing as an attendee → should see audit logs
3. Try accessing as a team admin/owner → should see audit logs
4. Try accessing as an unrelated user → should get 403 Forbidden error
5. Try accessing with invalid booking UID → should get 404 Not Found error
6. Test search functionality with various terms
7. Test filtering by action type and actor type
8. Expand/collapse log details to verify JSON rendering
9. Test with booking that has 0 audit logs → should show "No audit logs found"

Environment variables:

• Standard Cal.com development environment
• No additional variables required

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. If N/A, write N/A here and check the checkbox.
• I confirm automated tests are in place that prove my fix is effective or that my feature works.

Checklist

• I haven't read the contributing guide
• My code doesn't follow the style guidelines of this project
• I haven't commented my code, particularly in hard-to-understand areas
• I haven't checked if my changes generate no new warnings